# Anthropic 官方 - 大规模代码迁移方法

> 学习 Anthropic 官方的六步迁移法，用 AI 高效完成大规模代码迁移



大家好，我是程序员鱼皮。

前几天 Anthropic 官方发了 [一篇博文](https://claude.com/blog/ai-code-migration)，讲的是他们内部如何用 Claude Code 跑大规模代码迁移。

这篇文章的含金量非常高，因为里面的两个案例实在太炸裂了！

![](https://pic.yupi.icu/1/image-20260720133130758.png)

第一个案例，前端圈很火的工具 Bun 的创始人 Jarred Sumner（目前也是 Anthropic 的技术员工），用 Claude Code 把 Bun 从 Zig 语言重写到 Rust。整整 53 万行代码，只用 11 天就完成了，而且 100% 测试通过后合并上线。

第二个案例，Anthropic Labs 的联合负责人 Mike Krieger 只用了一个周末，把一个 Python 项目迁移成了 16.5 万行 TypeScript，全平台构建时间从 30 分钟降到了约 2 秒。

**一个周末，重构 16.5 万行代码，什么概念？**

以前这种量级的工程，再牛的团队也得干上一两年，还不一定能做到 100% 兼容。现在一个人加一个 AI，几天就搞定了。

大家肯定很好奇，他们是怎么做到的，这背后有什么方法和技巧吗？

下面我会结合官方博文的内容，加上 Bun 官方的技术博客、以及我自己使用 AI 编程的经验，给大家做一个完整的中文深度解读。

学会这套方法之后，几万行代码的项目重构、技术栈升级、老项目翻新，你都可以用同样的思路高效完成。



## AI 迁移代码的核心思路

用 AI 迁移代码时，你的工作不是修改代码，是在设置「产出代码的流程」。

传统的代码迁移思路是一个文件一个文件地翻译，翻译完了逐个检查，发现问题逐个修复。

这种方式在几十个文件的规模还可行，但如果文件数量成百上千，基本就不可能了。

正确的思路是 **把注意力放在流程上**。

当你发现 AI 在某类翻译上反复犯同样的错，不要一个一个去修那些错误的代码，而是去修复规则手册，让所有后续翻译都不再犯这个错。随着规则越来越完善，你需要人工干预的次数会越来越少。

![](https://pic.yupi.icu/1/01_%E4%BF%AE%E6%B5%81%E7%A8%8B%E4%B8%8D%E4%BF%AE%E4%BB%A3%E7%A0%81%EF%BC%9A%E6%A0%B8%E5%BF%83%E6%80%9D%E8%B7%AF%E5%AF%B9%E6%AF%94_compressed_v1.png)

我刚开始用 AI 编程的时候，经常是一个个修复 Bug。AI 犯了一个错，我纠正一次，下次又犯同样的错，我再纠正一次。反反复复，非常低效。

后来我开始把踩过的坑写进 CLAUDE.md / AGENTS.md 或者 Rules 文件里，每次纠正 AI 的错误都顺手沉淀成规则。

随便举个例子，比如我发现 AI 生成 Spring Boot 接口时总是忘记加参数校验注解，我就加了一条规则：

```markdown
所有 Controller 层的请求参数必须使用 @Valid + DTO 校验，禁止在 Service 层手动 if 判空
```

从此再也没出现过这个问题。

所以无论是百万行代码迁移，还是你平时 Vibe Coding 项目，都应该有这个意识：**出了问题不要只盯着问题本身，要修复产出问题的源头**。



## 六步迁移法

Anthropic 总结了一套完整的大规模代码迁移流程，总共六步。

开局一张图，你就知道这套方法论大概有多 NB 了。

![六步迁移流程总览](https://pic.yupi.icu/1/07_%E5%85%AD%E6%AD%A5%E8%BF%81%E7%A7%BB%E6%B5%81%E7%A8%8B%E6%80%BB%E8%A7%88%EF%BC%88%E4%B8%AD%E6%96%87%E7%89%88%EF%BC%89_compressed_v1.png)



### 0、搞定验证机制

在动手迁移之前，你必须有一个可靠的验证机制。没有验证机制，你都不知道什么时候可以收工。

最理想的情况是像 Bun 一样，已经有一套完整的测试套件，而且测试是用第三方语言写的（Bun 的测试用的是 TypeScript），不依赖被迁移的语言本身。

但如果你的测试跟源代码是同一种语言写的呢？

建议是先把测试分类。哪些测试是通过外部接口验证行为的？哪些是依赖内部实现细节的？

外部接口的测试可以直接复用，内部实现的测试需要重写成跟语言无关的形式。

开头提到的例子中，Mike 的项目没有现成的测试套件，他的做法是让 Claude 创建了一个 **对比脚本**，跑 7 个真实场景，把 Python 版本和 TypeScript 版本的输出做 diff，任何行为差异都算 Bug。

这个思路对小项目也完全适用。哪怕你只是把一个 Python 脚本迁移到 TypeScript，也可以让 AI 帮你准备几组真实的输入输出样本，迁移完了跑一遍，看看结果一不一样。



### 1、制定规则手册和依赖图

这一步是整个流程里人工投入最多的阶段。

![](https://pic.yupi.icu/1/08_%E7%AC%AC1%E6%AD%A5%EF%BC%9A%E5%88%B6%E5%AE%9A%E8%A7%84%E5%88%99%E6%89%8B%E5%86%8C%E5%92%8C%E4%BE%9D%E8%B5%96%E5%9B%BE%EF%BC%88%E4%B8%AD%E6%96%87%E7%89%88%EF%BC%89_compressed_v2.png)

Bun 创始人 Jarred 光是跟 Claude 讨论怎么把 Zig 的模式映射到 Rust 就花了 3 个小时，最终产出了一份 576 行的规则手册，里面详细规定了每种类型怎么映射、每种惯用法怎么转换。

规则手册的内容取决于一个关键策略：**新代码是保持原有架构逐行翻译，还是完全重新设计？**

Jarred 选择的是保持架构不变的机械翻译，所以他的规则手册主要是一个对照表。他还让 Claude 跑了一个工作流，分析代码库里每个 struct 字段的生命周期，输出成一个 `LIFETIMES.tsv` 文件给后续翻译参考。

![](https://pic.yupi.icu/1/image-20260720171445547.png)

而 Mike 选择的是重新设计架构，所以他的规则手册更像是一份设计文档，描述新系统应该长什么样。

除了规则手册，依赖图也很重要。你得知道哪些文件依赖哪些文件，这样才能决定迁移的顺序、哪些文件可以放在同一批处理。

对于像 Python 这种依赖关系不显式声明的语言，可以让 Claude 写一个脚本去分析和生成依赖图。Anthropic 还开源了一个 [代码迁移工具包](https://github.com/anthropics/code-migration-kit-with-claude-code)，里面就包含了现成的依赖分析脚本，拿来直接用就行。

![](https://pic.yupi.icu/1/image-20260720171538243.png)

此外，还要做一份「差异清单」，列出源语言和目标语言之间那些不能简单翻译的地方。

比如 Zig 到 Rust 的核心差异是手动内存管理变成了所有权系统，Python 到 TypeScript 的核心差异是动态类型变成了需要显式声明接口。这些差异点是 AI 最容易犯错的地方，必须在规则手册里重点标注。



### 2、小范围试跑

规则手册写好之后，不要急着全量执行，先拿 3 个文件试试水。

![](https://pic.yupi.icu/1/09_%E7%AC%AC2%E6%AD%A5%EF%BC%9A%E5%8E%8B%E5%8A%9B%E6%B5%8B%E8%AF%95%E8%A7%84%E5%88%99%EF%BC%88%E4%B8%AD%E6%96%87%E7%89%88%EF%BC%89_compressed_v1.png)

我觉得 Bun 创始人 Jarred 的做法很机智。他让一个 Claude 实例按照规则手册翻译 3 个文件，同时让另一个 Claude 实例以「高级 Rust 工程师」的身份翻译同样的 3 个文件。然后再开一个全新的 Claude 对话，专门用来对比两个版本的差异，从差异中提取新的翻译规则。

这一步他发现了 2 个关键问题，如果直接铺开到全部 1448 个文件，后果不堪设想。

对于重新设计架构的项目，做法不太一样。Mike 是让多个 Claude 实例从不同角度挑设计文档的毛病，看有没有逻辑漏洞或考虑不周的地方。然后跑一次完整的端到端翻译，看看设计在实际执行中有没有问题，发现了问题就改规则、重跑。

有趣的是，他实际上跑了三次完整迁移，**前两次都丢弃产出，只保留对规则的改进，直到第三次才正式保留结果。**

![](https://pic.yupi.icu/1/02_%E8%AF%95%E8%B7%91%E5%93%B2%E5%AD%A6%EF%BC%9A%E5%89%8D%E4%B8%A4%E6%AC%A1%E4%B8%A2%E5%BC%83%E5%8F%AA%E4%BF%9D%E7%95%99%E8%A7%84%E5%88%99%E6%94%B9%E8%BF%9B_compressed_v1.png)

我看到这里，第一反应是：前两次直接丢弃，这不是浪费 Tokens 么？

但其实，对于复杂的项目来说，这么做是合理的。试跑阶段的目标就是打磨规则，试跑出来的代码未必正确可用，如果直接应用这些代码，搞不好会影响整个项目迁移。

这点对普通开发者也很有启发。很多人用 AI 做项目的时候，总想着一步到位。其实不妨先让 AI 做一个粗糙的版本，看看哪里不对，完善好提示词和规则之后再正式开始，磨刀不误砍柴工。



### 3、全量翻译

规则经过试跑验证之后，就可以全量执行了。

这一步的核心架构可以理解为一个流水线，分为 3 个角色：负责翻译的 Agent、负责找茬的 Agent、负责修复的 Agent。

![](https://pic.yupi.icu/1/10_%E7%AC%AC3%E6%AD%A5%EF%BC%9A%E5%85%A8%E9%87%8F%E7%BF%BB%E8%AF%91%EF%BC%88%E4%B8%AD%E6%96%87%E7%89%88%EF%BC%89_compressed_v1.png)

每个翻译好的文件由 2 个独立的「找茬 Agent」来检查，它们的唯一任务就是挑毛病。发现问题后交给「修复 Agent」来处理。

![三角色 Agent 流水线](https://pic.yupi.icu/1/03_%E4%B8%89%E8%A7%92%E8%89%B2Agent%E6%B5%81%E6%B0%B4%E7%BA%BF%EF%BC%9A%E7%BF%BB%E8%AF%91%E3%80%81%E6%89%BE%E8%8C%AC%E3%80%81%E4%BF%AE%E5%A4%8D_compressed_v2.png)

这里的找茬 Agent 就是前面提到的「对抗性审查」。

为什么叫对抗性呢？

因为审查者被明确要求「假设这段代码是有 Bug 的，你的任务是找出 Bug 在哪」。

这种心态跟人做代码审查是一个道理，审查者不能先入为主觉得「他写的应该没问题吧」？而是要带着怀疑的态度去看，才能发现问题。

![对抗性审查](https://pic.yupi.icu/1/04_%E5%AF%B9%E6%8A%97%E6%80%A7%E5%AE%A1%E6%9F%A5%EF%BC%9A%E6%80%80%E7%96%91%E5%BF%83%E6%80%81_vs_%E4%BF%A1%E4%BB%BB%E5%BF%83%E6%80%81_compressed_v3.png)

听起来很简单，但是要注意几个实操细节。

1）工作队列要机械化。比如什么文件翻译了、什么文件没翻译，可以通过检查磁盘上有没有目标文件来判断。这样整个流程天然可恢复，中断了重启就行，不需要维护什么状态。

2）翻译 Agent 和审查 Agent 的对话必须隔离。写代码的 AI 总是倾向于认为自己的代码没问题，所以审查者必须在一个全新的独立对话里工作，只看翻译结果，不看翻译过程中的推理。

3）模型要分层使用，不需要所有步骤都用最强的。实现翻译这种高并发的工作可以用相对便宜的模型（比如 Claude Sonnet），而审查和规则制定用最强的模型（比如 Claude Fable、Claude Opus）。Mike 在全量翻译阶段就是用 12 个 Sonnet 子代理并行工作的。

翻译时如果有拿不准的地方，直接标上 `// TODO(port): <原因>`，不要在这一步纠结，后面编译器和测试会告诉你到底对不对。



### 4 ~ 6、编译 + 运行 + 对齐行为

接下来的 3 步套路都一样：先跑一遍得到错误列表，然后让一批修复 Agent 并行处理这些错误，修完了再跑一遍，循环往复直到没有错误为止。人工介入的程度越来越低。

![错误驱动修复循环](https://pic.yupi.icu/1/05_%E9%94%99%E8%AF%AF%E9%A9%B1%E5%8A%A8%E4%BF%AE%E5%A4%8D%E5%BE%AA%E7%8E%AF_compressed_v3.png)

1）编译阶段，把编译器报出的所有错误整理成一份待修复清单，然后让 AI 按照这份清单逐个修复。

Jarred 的做法是让编排脚本对整个工作区跑一次编译器，把错误按模块分组输出到文件，然后 64 个「修复 Agent」并行处理错误列表。每个修复 Agent 有 2 个对抗性审查者盯着。修复完再编译，反复循环。

这一步他遇到了一个大问题。

原来的 Zig 代码是一整坨放在一起编译的，他想把 Rust 代码拆成 100 个独立模块来加快编译速度，但这引入了大量循环依赖问题。

于是，他跑了一个专门的工作流来分类哪些代码该挪到哪里，修复循环依赖之后暴露出约 16000 个编译错误。16000 个错误对人来说是天文数字，但对 64 个并行的 Claude 来说，也就是几个小时的事。

2）冒烟测试阶段，把所有崩溃信息整理成待修复清单。

编译通过之后，先让各个子命令跑起来，把每个崩溃的报错信息和对应的子命令保存到文件，用同样的「修复 + 审查」循环处理。

3）行为对齐阶段，把所有失败的测试整理成待修复清单。

把测试套件分片跑，每个失败的测试交给一个修复 Agent，修复之后由对抗性审查者检查。

![](https://pic.yupi.icu/1/11_%E7%AC%AC4-6%E6%AD%A5%EF%BC%9A%E7%BC%96%E8%AF%91%E3%80%81%E8%BF%90%E8%A1%8C%E3%80%81%E8%A1%8C%E4%B8%BA%E5%AF%B9%E9%BD%90%EF%BC%88%E4%B8%AD%E6%96%87%E7%89%88%EF%BC%89_compressed_v1.png)

Jarred 还有一个巧妙的设计，只允许一个专门的构建守护进程来编译整个项目。修复 Agent 只提交代码，守护进程定期把所有补丁批量编译、跑受影响的测试、把结果反馈回去。这样避免了多个 Agent 各自触发编译导致的资源冲突和重复工作。

整个过程中，Bun 的 CI 从 972 个测试文件失败到全部通过，花了大约 4 天。Linux 最先变绿，Windows 是最后一个。合并之后一共出现了 19 个回归 Bug，全部已修复。

![](https://pic.yupi.icu/1/image-20260720165511010.png)

其实 Airbnb 之前也做过类似的事情。他们用 AI 把 3500 个 React 组件测试从 Enzyme 迁移到 React Testing Library，原本估计要一年半，最终 6 周就完成了，用的也是类似的方法。



## 我的感受

看完 Anthropic 这套六步迁移法，说几个我自己比较有感触的点。

首先是对抗性审查这件事，大家日常用 AI 编程时完全可以做。比如让一个 Agent 写完代码之后，开一个新的对话让另一个 Agent 做 code review。在 Claude Code 里面可以直接用内置的 `/code-review` 命令，或者用 Subagent 来做审查。哪怕不做代码迁移，这个习惯也值得养成。

然后是 AI 的成本问题。你敢信？Bun 的迁移花了 **16.5 万美元**的 API 费用！

![](https://pic.yupi.icu/1/image-20260720182903395.png)

这个数字乍一听很吓人，但对比 3 个高级工程师干一年的薪资加机会成本，便宜太多了。

对于个人开发者来说，一个几万行的项目迁移用 Pro 或者 Max 的订阅额度基本就够了。至于这个钱花的值不值，自己用人力成本算一笔账就好。

不过不要盲目跟风迁移。如果现有代码跑得好好的、也不难维护，就没必要折腾了。

**迁移的前提是你确实有一个持续的痛点需要解决。**

像我之前在 Claude Fable 5 限时可用的那几天里，疯狂优化自己的工作流，结果纯粹是为了优化而优化，也没什么效果，主要是之前 Opus 做的已经很好了。

还有很关键的一点，**人的判断力仍然不可替代**。

Jarred 在整个迁移过程中，每天都在监控工作流的输出、手动检查 AI 的行为、发现系统性问题后调整流程。

虽然 AI 执行力很强，但决策权还是在人这边。

AI 能节省成本，但不代表完全不需要人。



## 写在最后

帮大家总结一下本文提到的方法，你立刻就能用起来：

1）做任何稍大的重构或迁移之前，先跟 AI 聊出一份规则文档，把「什么该怎么改」定义清楚，别上来就动手。

2）先拿 3 个文件试跑一轮，看看 AI 会犯什么错。发现的问题不要逐个修代码，而是补到规则文档里，然后重新生成。

3）写代码的 AI 和审查代码的 AI 一定要分开。可以用 Claude Code 的 `/code-review` 命令，或者开一个新对话做独立审查。

4）善用「错误即清单」的思路。编译报错、测试失败、Lint 警告，这些都是天然的任务列表，让 AI 按清单逐个修复就好。

想想看，连几十万行、上百万行代码都能用 AI 完成迁移了，我们平时几千行、几万行的项目重构，还有什么不敢动的呢？

关键不在于 AI 有多聪明，现在模型的能力已经足够了，更多的要看你给 AI 设计的流程够不够好。

希望这篇文章能帮你建立起这个信心，学好如何驾驭 AI！